개요

이건 내가 컴퓨터를 껐다 키고 나서 kubectl을 쓰려 했을 때 나타난 에러를 본 것이다.
그 이후에는 직접 SSH로 컨트롤 플레인에 들어가서도 확인해봤더니 저 이슈인 것이다.
과거에, 내가 T-vagrant 쿠버 버전 업그레이드를 하기 이전에는 껐다켜도 이런 이슈가 없었다.

api 서버 설정 확인

kube-apiserver에는 문제가 없다고 생각한다.

컨테이너 런타임 확인 - 발견

문제는 여기 있었다.

에이.. 너무 간단한 이슈였다.
LoxiLB 측의 Vagrant파일을 많이 참고했는데, 부팅 간 스왑 메모리 비활성화를 제대로 하지 못하고 있었나 보다.
어쩐지 kubeadm init할 때 swap 체크를 건너뛰더라..
근데, 지금 안 그래도 스토리지 공부를 하는 김에 swap 메모리 가능하도록 하는 설정도 진행해볼까 한다.^[1]

설치 시점의 설정은 매우 간단하다.
그럼 설치가 완료된 시점의, 빌드 파일이 완료된 시점에 인자로 전달하는 것도 가능한가?
or the deprecated --fail-swap-on command line flag must be deactivated. 문서에 인자를 주는 부분이 있는 것으로 보아.. 가능하긴 할 듯.

재설치 없이 kubelet 설정하기

어디에서 인자를 넣어줄 수 있는가.
드롭인 부분을 보면 해당 서비스가 어떻게 설정되는지 알 수 있다.

기본 설정을 위한 인자들이 쭉쭉 들어가고, 마지막으로 $KUBELET_EXTRA_ARGS 부분에 유저가 커스텀하는 설정을 넣어주면 된다.

그리고 그 경로는 이쪽인데, 사실 여태 설정했던 vagrant파일에서 나와있기는 하다.

그래서 다 여기에 넣어서 해봤는데, 에러는 여전했다.

이번에는 config 파일을 수정한다.
위에 프로세스 실행 인자 중에 $KUBELET_CONFIG_ARGS에 이미 파일 경로가 명시돼있다.

데몬 리로드만 한 이후에 바로 프로세스가 동작하기 시작했다.

마스터 노드에만 설정을 해준 관계로.. 일단 그렇다.

설치 파일 kubelet 설정하기

방향은 두 가지가 있다.
swap을 허용할 것이냐, 아니면 swap을 끌 것이냐.
조금 더 고민을 해봤는데, 사실 여기에서 swap을 허용하는 설정을 하는 것은 어차피 방금 config 파일을 만지면서 해봤고, 흔한 케이스가 아니라고 생각해 후자로 가려고 한다.

설정이 잘못 됐던 건 제 설정이었군요.
이전 vagrant 박스 이미지에서는 먹혔는데 아무래도 이미지가 바뀌니 조금 다른 것으로 보인다.

이게 loxilb 측 설정이었다.
단순하게 리부팅될 때마다 swapoff를 할 수 있게 크론탭을 거는 것이다.

하지만 이 세팅 역시 문제는 있는 게, vm에는 아무런 변화가 발생하지 않았다.
아마 fstab의 설정이 @reboot 이후에 발생해서 스왑이 설정돼버린 게 아닐까 한다.

sudo swapoff -a && sudo sed -i '/swap/ s/^/#/' /etc/fstab
나는 내 내 설정을 다음과 같이 바꾸었다.
현재 fstab 파일은 단순 공백이 아니라 탭으로 구분되어 문자열 매칭이 실패하는 것 같다.
swap 이라는 문자가 들어간 행이 있다면, 해당 행의 맨 앞을 주석 처리한다.

성공적으로 완수됐다.

결론

swap 기능 활성화 조심하자!

메모리 스왑의 위험성

메모리스왑은 노드에서 사용가능한 메모리 사용량을 측정하기 어렵게 만든다.
그래서 QoS를 통해 원하는 동작을 수행하도록 하는 것도 어려워지기에, 가급적 사용을 안 하는 것이 권장된다.
그럼에도 사용하고 싶다면 BestEffort, 즉 가장 먼저 축출되어도 되는 파드들이 해당 메모리를 사용하는 것이 좋을 것이다.

추가적으로 Secret은 원래 메모리의 영역에만 저장되어 휘발되는 것이 보장되는 오브젝트이다.
그러나 메모리 스왑 공간에 시크릿이 저장되면 민감한 데이터가 디스크에 저장되어 심각한 보안 문제를 야기할 수 있다.

뭐.. 그런데 현재 알파 버전의 상태이고 점차 발전해나가면서 이런 문제가 해결될 가능성은 있다.

관련 문서

참고